Power Utilities/Power Utilities.iso/utility/pro225/kermit.bwr

Text File | 1993-07-10 | 99.4 KB | 2,079 lines

File MSKERM.BWR           MS-DOS KERMIT 3.13 "BEWARE FILE"              July 1993

               BUGS, LIMITATIONS, HINTS & TIPS

Last update: Thu Jul  8 18:56:14 1993

This file discusses common problems installing or using MS-DOS Kermit and
presents solutions or workarounds in many cases.  It applies to version 3.13
of MS-DOS Kermit for the IBM PC family and compatibles.  See KERMIT.HLP
(MSKERM.HLP) for copyright information, terms and conditions, and a summary of
MS-DOS Kermit commands.

The user manual for MS-DOS Kermit 3.13 is the book "Using MS-DOS Kermit",
Second Edition, by Christine M. Gianone, published by Digital Press, Bedford,
MA (1992), order number EY-H893E-DP.  Call 1-800-344-4825 (toll free, USA) to
order, or order from Columbia University.  Changes since the book was
published are described in KERMIT.UPD (MSKERM.UPD).

Please consult "Using MS-DOS Kermit" and this file before contacting Kermit
technical support staff.  Report problems via e-mail to [e-mail] on
the Internet or to [e-mail], or call [phone], or by Fax to
[phone], or write to Kermit Distribution, Columbia University Academic
Information Systems, 612 West 115th Street, New York, NY 10025, USA.

INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.13 AND EARLIER VERSIONS:

 1. The TERMINALR/S macro capability is replaced by host-initiated change
    of screen writing direction (details in KERMIT.UPD).  As a consequence
    of this, host-based WordPerfect won't be able to load your key settings
    (see next section).  Any other host software that sent the TERMINALR/S
    sequences will also need to be converted in similar fashion.  See the
    APC section in KERMIT.UPD (MSKERM.UPD) for further details.

 2. STATUS command removed.  There is no longer any way to display all of
    MS-DOS Kermit's settings on a single screen.  Now use the SHOW command to
    display categories of settings: SHOW TERMINAL, SHOW COMMUNICATIONS, SHOW
    PROTOCOL, etc.

 3. STATISTICS, which displays file transfer statistics, has been added as a
    top-level command, for compatibility with C-Kermit.     So if you were used
    to typing "stat" to get a screenful of settings values, now you will get
    file transfer statistics instead.

 4. Alt-n was previously bound by default to the \Knethold verb.  It is now
    bound to the new \Knextsession verb.  \Knethold (used on TES, EBIOS,
    NASI/NACS, and various other PC networks or asynchronous communication
    servers) has been moved to Alt-z.

WORDPERFECT

To make host-based UNIX WordPerfect work with MS-DOS Kermit 3.13, follow these
directions (courtesy of Chris Thompson at Vanderbilt University).  Presumably
similar steps can be followed for the VMS version:

. Go into the directory where the terminal definitions are stored (in my case
  of WP 5.1 for AIX, it was /usr/wp51/shlib), and execute "wpterm" (it usually
  requires you to be super-user).

. A screen containing all the terminal definitions will appear.  Highlight the
  current Kermit terminal definition and hit Create.

. It will ask "Model new definition after Kermit?"  Answer yes.

. It will then ask for a new name for your new terminal definition.  Call it
  something like KERMIT313.

. At the bottom of the screen, several options will appear.  Choose the option
  for Terminal Control Characters.  It will then bring up a screen with the
  different initialization strings and their values.  The first four items are
  the ones that need altering (Terminal Initialization, Terminal Reset, Quick
  Initialization, and Quick Reset).  Just delete "[27][?34h" or "[27][?34l"
  (for initialization and reset, respectively) from the string and replace it
  with "[27]_take \kermit\wpunix.ini[27]\" or "[27]_set key clear[27]\",
  leaving the rest of the string intact.

. Be sure to change your WPTERM environment variable if you decided to create
  a definition with a different name.

TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS

  "Why can't MS-DOS Kermit find my COM3 or COM4 port?"
  "Why can Kermit send characters to my COM port, but not read them?"
  "Why doesn't Kermit work with my internal modem?"

Rule out the obvious: Is everything connected and turned on?  Did you
give a SET PORT command for the right device, and did you give it BEFORE any
other device-related commands, such as SET SPEED and SET PARITY?  Remember,
port-related settings apply to the port that was selected in the most recent
SET PORT command, so a proper sequence might be:

  SET PORT COM2          ; First select the port
  SET SPEED 19200     ; Then set its speed
  SET PARITY EVEN     ; and other parameters for this port...
  SET FLOW RTS/CTS
  SET LOCAL-ECHO ON

Each of these parameters is remembered for each port, so switching ports (e.g.
SET PORT COM1 after you have given the above sequence of commands) changes
all these parameters to their previous (or default) values for the port you
have switched to.  To see communication parameters for the current port:

  SHOW COMMUNICATIONS

Check them carefully to be sure they are what you intended.

  The following discussion is detailed and technical, but most of it boils
  down to (a) telling Kermit two numbers, the port address and IRQ value; and
  (b) fiddling with your modem.     Keep that in mind as you read more about PC
  hardware than you ever wanted to know.

HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE

DOS PCs come with full support for two communication ports, COM1 and COM2, and
with provisions for two more, COM3 and COM4.  COM3 and COM4 are not well (or
consistently) supported in most types of PCs, as are COM1 and COM2 which
rarely (by themselves) cause any problems.  This discussion considers only
COM1-COM4, since higher-numbered COM ports are rare, and in any case not
supported by MS-DOS Kermit.

The digit in the port name (like the "2" in COM2) is an index into an area in
memory that contains the address of the serial port hardware.  The PC's Basic
Input/Ouput System (BIOS) has four words starting at segment 40 (hexadecimal),
word 0, for the addresses of the first four COM ports.  Word 0 is for COM1,
word 2 (two bytes per word) for COM2, word 4 COM3, and word 6 COM4.  To view
these addresses:

  C:\> debug         (start the debug program)
  -d 40:0         (display segment 40)
  -q             (quit the debug program)

("C:\>" is the DOS prompt, "-" is the debug prompt.)  Here are the results
on a PS/2 with 3 COM ports:

  0040:0000  F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03  .... 2........`.
             ^^^^^ ^^^^^ ^^^^^ ^^^^^
             COM1  COM2  COM3  COM4

The first line (like the one above) contains the COM port information (ignore
the other lines, as well as the characters on the right).  "F8 03" is the
2-byte COM1 address, expressed in hexadecimal (base 16) with the low byte
first.  Thus the actual COM1 address is 03F8 hex, expressed in Kermit commands
as \x3f8.  The COM2 address is 02F8, the COM3 address is 3220, and (since
there is no COM4) the COM4 address is 0000.  That is how both DOS and the BIOS
understand which ports are defined and where to find them.

When your PC is powered up, the BIOS startup code checks for serial port
hardware (that is, a Universal Asynchronous Receiver/Transmitter, or UART) at
the two port addresses 03F8 and 02F8.  If it finds a UART at the first address
then that address is placed in word 40:0 and declared to be COM1.  Then the
BIOS tries the second address and if successful this address goes into the
first available word at that time, typically 40:2 as the address of COM2.
Thus if you remove a COM1 device then a previously COM2 device will appear in
the COM1 BIOS storage area as COM1 to DOS and Kermit.  What happens to the
other two words depends on the PC model and BIOS.  The IBM PS/2 BIOS fills in
all four words on startup, but most others handle only the first two because
that's how IBM did it with the original PCs.

  So... just setting switches or jumpers on a serial port board or internal
  modem does NOT necessarily define the board to be a particular COM port.

So why do some communication programs work with COM3 and COM4 without any
special fiddling?  These programs ASSUME certain COM3 and COM4 addresses, even
when there are no entries in the BIOS communication-port area.  Some of these
programs show you their assumptions in a menu (and might allow you to change
them), others do not.  The assumed values are usually as follows:

  Port     Assumed Address (hexadecimal)
  COM1          03F8
  COM2          02F8
  COM3          03E8
  COM4          02E8

  NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and 3228,
  respectively.  Well-behaved communication software (like Kermit) will use
  these addresses rather than the defaults listed above.  Ill-behaved software
  ignores the segment-40 addresses and erroneously attempt to use its own
  values, right or wrong.

Unchecked use of an assumed port address is DANGEROUS if the device is not
really where the software expects, especially if some other kind of device,
say a network adapter, is at the given address.  It can also produce unwanted
conflicts under Windows, OS/2, and DesqView, whose drivers often set the
port's segment-40 word to 0 when they want to use the port exclusively and
without interference, and then restore the real address when done, and similar
unwanted interference with Int 14H redirectors that allow serial-port
communication software to be used on network connections.

Unlike most other PC communication software, Kermit does NOT attempt to use a
communications port unless:

  (a) It finds its address in the BIOS comm-port area, segment 40, or:
  (b) You specify the address yourself.

AND:

  The device at the given address passes certain tests, in which registers
  must contain certain values that are legitimate for a UART.

In other words, KERMIT IS MORE CAREFUL than most other communication software,
because does not want to risk disrupting normal operation of your PC.

SPECIFYING THE PORT ADDRESS

If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4), and
Kermit responds:

  Warning, no hardware for this serial port.
  This port will be operated through the BIOS as BIOSn

it means that Kermit did not find an address for the port in the BIOS area or
it did find one but the hardware at that address did not look like a UART.  If
the cause of the message is a missing address, you can tell MS-DOS Kermit the
address of the port by issuing the following command:

  SET COMn \xhhhh

where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9, A-F)
representing the 16-bit address.  This command not only informs Kermit of the
address, but also inserts the address into the BIOS so other programs can find
the port (if they follow the rules), and so you don't have to give this
command to Kermit again until after the next time you reboot.

After giving the SET COMn command, give a SET PORT COMn command for the same
port, e.g.:

  set com3 \x3f8   ; FIRST specify the address of COM3
  set port com3       ; THEN select COM3

How do you know what addresses to give?     If have purchased an internal modem
or an add-on serial port, the installation instructions should tell you.  The
device must be configured -- generally by setting little switches or
installing or removing jumpers.     You have to make sure that the address that
you have chosen agrees with the address that Kermit will use.

Although it is not recommended that you guess at address values, sometimes it
is the only way (as often with inherited equipment), for which occasions here
is a list of the addresses commonly used for serial ports and internal modems:

  Port     Likely Addresses (hexadecimal)
  COM1         03F8
  COM2         02F8
  COM3         03E8, 3220 (PS/2)
  COM4         02E8, 3228 (PS/2), 02E0

You probably won't find a serial port at any address not listed above, but you
might find a port at another port's expected address.  The use of these
addresses in SET COMn commands should be relatively harmless (provided you
don't also specify an interrupt, explained later); if there is no error
message, Kermit found a possibly usable port. If there is an error message, no
harm should have been done.

Now let's look at the other cause for the "This port will be operated through
the BIOS" message, namely that an address was found in segment 40, but the
device at that address does not appear to be a genuine serial port.
Explanations might include:

 1. The device is at a different address.  Check your device's configuration
    again, or else your SET COMn command.

 2. Your device is indeed at the given address, but its registers do not
    contain values expected of a true PC serial port.  In that case, BIOS
    operation is the only alternative.

 3. Your device is at the given address, but there is a conflict with another
    device at that address or the machine's bus speed (not CPU speed) is set
    so high that the hardware test gave confusing results.

When Kermit operates a port through the BIOS, rather than directly, it will be
MUCH slower and might not work at all because the BIOS requires the CD, CTS,
and DSR modem signals to be asserted by the device connected to the port (and
the CD signal is normally NOT asserted by a modem before it has made a
connection to another modem).  In that case, you will have to configure the
device (e.g. modem) to assert DSR, CTS, and CD always, or wire your modem
cable to fake these signals (e.g. by connecting CD and DSR together).

Assuming you have found the right address for your COM3 or COM4 port (or
nonstandard address for COM1 or COM2), and you want these addresses to be set
correctly for Kermit at all times, even if it doesn't read its initialization
file, you can put a command like the following in your AUTOEXEC.BAT file:

  set kermit=com3 \x3e8; com4 \x2e8;

INTERRUPTS

  "I can send characters to the modem, but I never see any on my screen."

This complaint (often arising from the user's observation of the modem lights
and speaker), also known as "can-talk-but-not-listen syndrome", usually means
that the communication device was found at the expected address, but Kermit's
idea of its interrupt is wrong.     What's an interrupt?

To achieve high-speed communication without impacting other applications,
Kermit reads characters from a serial device using "interrupts".  Whenever a
character arrives at the serial device, the device sends a signal, called an
interrupt, that can be "caught" by application software like Kermit, leaving
the application free to do other work in the meantime without having to
constantly look at the serial port to see if any characters have arrived (an
operation called "polling", which is used by some other communications
programs).  Communications programs that use polling are not sensitive to
interrupts being set improperly and might therefore work with improperly-
configured machines where Kermit will not (until you give it the required
information), but they also tend to take over the entire computer.

In contrast to polling programs, Kermit is normally waiting for input from the
keyboard, and is therefore idle if you are not typing and no characters are
arriving at the communication port.  In multi-tasking environments such as
Windows or OS/2, this allows other applications the largest possible share of
the CPU while Kermit is running.

When a character arrives at the port, an interrupt signals Kermit to wake up
from its keyboard-wait state and read the character from the port.  But Kermit
needs a way of knowing which device the interrupt came from, so it will not
erroneously read characters from the wrong one.  The device is identified by
an Interrupt Request (IRQ) number, a small number like 3 or 4.  The BIOS does
not record the IRQ number used by a serial port because the BIOS uses polling
rather than interrupts.  The communications software has to know which IRQ to
use.  By convention from the original IBM PC, COM1 uses IRQ 4 and COM2 uses
IRQ 3.  There is no standard for COM3 and above, but certain conventions are
normally followed:

  Port     PS/2  Others
  COM3     IRQ3    IRQ4
  COM4     IRQ3    IRQ3

  WARNING: Certain serial port cards and internal modems allow
  themselves to be configured with different IRQ numbers (such as 9),
  even on COM1 or COM2.     Check your device's installation instructions.

Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers, provided
each application has its own interrupt service routine and each such routine
is built to "chain" interrupts properly (i.e. pass them along to other
applications if they have arrived at the wrong place).  This works, for
example, with Kermit on a PS/2; you can run two copies of Kermit under
Windows, one using COM2/IRQ3 and the other using COM3/IRQ3 (i.e. two ports,
same IRQ), both doing input and output simultaneously with no confusion.  But
on most types of PCs, IRQs can NOT be shared, so each device must have a
unique IRQ number. This caution applies especially when you have a serial
mouse on IRQ 3 or 4.

Once Kermit knows the COM port's address, it tests to see which IRQ number, 3
or 4, the device uses.  This is a safe test and doesn't cause any modem
signaling or communication to take place.  The PC architecture has a limited
range of IRQ numbers available, and so (usually) there can not be a unique IRQ
number for each serial port when there are more than two, so in most cases no
more than two serial ports can be active at once.

MS-DOS Kermit tests first for IRQ4, and then if there is no response, IRQ3.
If both tests fail, a default value is used (on PS/2s, the default is IRQ4 for
COM1 and IRQ3 for COM2-4; on others is it is IRQ4 for COM1 and COM3, IRQ3 for
COM2 and COM4).     No error message is given in this case, but
"can-talk-but-not-listen syndrome" is a likely result.

Some add-on communication boards or internal modems are set up to use IRQ
numbers other than 3 or 4 in order to avoid conflicts with COM1 or COM2 and/or
to allow more than two COM ports to be active at once. But this can be
dangerous -- for example, IRQ 5 (which is often used for this purpose) is also
used by the hard disk controller on the PC/XT.  IRQ 7 is often used by network
boards.  For this reason, Kermit does not automatically test any IRQ numbers
other than 3 or 4, and does not use any other IRQ number by default.

But it is sometimes necessary, particularly on ISA (Industry Standard
Architecture) bus machines (PC/ATs and compatibles) and earlier (such as PCs
and XTs) to use an IRQ other than 3 or 4, for example when when an internal
modem is installed as COM3 on IRQ4, and then use of COM1 prevents COM3 from
working, and vice versa.  This problem can often be solved by reconfiguring
the board to use an otherwise unused unique IRQ number.  Ideally this would be
a normally free IRQ such as 10 or 11, but unfortunately most communication
boards are not configurable for IRQs higher than 7.  Here is a brief, and
definitely not comprehensive, guide to the low IRQ numbers (with IRQ numbers
expressed in decimal):

     2    Normally available, but some video boards use it to obey an obsolete
    standard for indicating vertical refresh.  Adjust video board jumpers
    to not do this.     On 286's and above, IRQ 2 is also known as IRQ 9:
    same IRQ, alternate number.  Windows 3.0 had difficulty with devices
    using IRQ 2, but Windows 3.1 is better.

     3    Normally COM2 and COM4.     PS/2's use IRQ 3 for all serial ports above
    COM1.  IRQ3 is also a favorite "factory default" of many local area
    network (LAN) adapters.

     4    Normally COM1 and informally COM3 (except on PS/2s).

     5    Secondary parallel port.  Parallel ports are rarely interrupt-driven
    (except for Novell RPRINTER users) so this wire becomes free if
    you unjumper the IRQ on the parallel port board.  LAN adapters are
    frequently placed on IRQ 5.  PC/XTs use IRQ 5 for the hard disk.  Be
    careful with this one.

     6    Floppy disk drives. Leave it alone!

     7    Primary parallel port.    Remove as described for IRQ 5.    Be careful,
    LAN adapters are frequently placed here.

     9    Alias for IRQ 2.

    10    Usually free.

    11    Usually free.

    12    Used by the IBM bus mouse, otherwise usually free.

    13    Math coprocessor errors are trapped here, otherwise frequently free.

    14    Used by hard disk on 286 and above.  Leave alone!

    15    Some SCSI controllers use this.     Usually free.

If your communication board uses an IRQ other than 3 or 4, you will experience
the "can talk but not listen" syndrome when using Kermit.  To fix it, simply
inform Kermit of the device's IRQ number.  This is done in the SET COMn
command, after the address:

  SET COMn <address> <irq>

for example:

  SET COM3 \x03e8 5

When you include a number (like 3, 4, 5, 6, or 7) after the port address
(separated by a space), Kermit skips its IRQ test and uses the IRQ number you
specified the next time you give a SET PORT command for that port.

  AVOID address and IRQ conflicts; these items MUST NOT overlap existing
  equipment. SERIOUS DAMAGE can result if, for example, the IRQ number you
  give is the same as the one used by your disk controller or network
  adapter.  Incorrect operation can result if the interrupt is in use by a
  less critical device, such as a mouse.

It is necessary to specify the IRQ number in either of these two situations:

  1. The communication device uses an IRQ number other than 3 or 4.

  2. Kermit's IRQ test interferes with Windows or a similar environment.

Check your PC's configuration carefully before specifying an IRQ number.
Before starting Kermit, you can use certain public domain or commercial
utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck MFT, or the MSD
utility shipped with Windows 3.1 to get an idea of which IRQ numbers are
already in use (these utilities are, of course, not foolproof -- for example,
they can't tell what IRQs are used by programs that are not presently loaded).

If, even after establishing the device's interrupt, Kermit still fails to
operate correctly (or reliably), check to see whether:

  1. Some other device (such as a mouse or LAN adapter) is generating the
     same interrupt.

  2. Some other software (such as a mouse or video driver) is catching the
     same interrupt.

If you find a conflict, you'll have to resolve it: remove the offending device
driver or TSR from your CONFIG.SYS or AUTOEXEC.BAT file or turn it off
temporarily (e.g. with the MOUSE OFF command for certain mouse drivers); or,
if possible, reconfigure one of the conflicting devices to use a different
interrupt.

Example: A PC (not PS/2) is delivered with a serial mouse on COM1 and with
COM2 as a free serial port.  COM2 can be used with an external modem, but you
can't put an internal modem on COM3 because its IRQ conflicts with the mouse
and the COM4 address clashes with an 8514/A video adapter (such as the ATI
Ultra+).  Neither the mouse interrupt nor the video board address can be
changed.  So to install an internal modem, you must remove the serial mouse
and driver and, if you need a mouse, replace it with a bus mouse.

PROBLEMS WITH MODEMS

  "I just bought and installed an XYZ V-Dot-Everything internal modem, and
  it works with <name-deleted> communication package, but not with Kermit".

This has long been a common complaint about internal modems.  The same
complaint is also now being heard with alarming frequency about some of the
newer external modems.  With internal modems, particularly when they are
installed on COM3 or COM4, the most common problems are:

 1. Kermit doesn't know the modem's address, or the device is using an IRQ
    number other than 3 or 4.  These problems can be fixed by giving the
    appropriate SET COMn command to Kermit.

 2. The internal modem is installed incorrectly, with an address or IRQ that
    conflicts with one already in use on your PC.

 3. The internal modem does not correctly emulate a real IBM PC serial port,
    and therefore fails Kermit's hardware test, and therefore can only be
    used through the BIOS.

 4. The device is in a laptop, notebook, or palmtop computer, and power to
    the internal modem or serial port has been disabled in the CMOS setup,
    or has been turned off automatically when the cover is closed or the
    machine shut down.

In mid-1992, a new generation of low-cost, high-speed modems, both internal
and external, began to appear on the market.  These modems typically offer a
wide range of features: V.32 and V.32bis modulation, V.42 and MNP error
correction, V.42bis and MNP data compression, etc.  Unfortunately, many of
these modems suffer from bugs not found in earlier modems.  The problems are
generally related to initialization of the modem and interaction with its
command processor.  Some common complaints:

 1. "The modem won't dial or respond to commands".  Or the modem ignores
    commands when Kermit's PARITY is set to a particular value, like EVEN.  Or
    commands are not processed correctly above a certain interface speed.

 2. "I can dial successfully, and in general send characters to and through
    the modem, but I never get any characters back."  This looks suspiciously
    like the "talk-but-not-listen" problem, but in some cases it is a bug in,
    or a configuration problem with, the modem, having nothing to do with
    Kermit: the modem is simply not sending any characters to the PC.

 3. "After using the modem with <name-omitted> communication software, it
    also works with Kermit, but it won't work with Kermit unless I run
    <name-omitted> first."

 4. "I can communicate in command-mode with the modem, up until I give it
    an ATZ command, at which point it seems to die."

 5. The modem does not pass the BREAK signal.

 6. The DSR signal goes off after successful dialing.

And so on.  All of these are modem, not Kermit, problems.  Some suggestions
for overcoming them:

 1. Before giving a DIAL command, which invokes a macro containing OUTPUT
    commands for the modem's command processor, give the command:

    SET OUTPUT PACING <milliseconds>

    For example:

    SET OUTPUT PACING 100
    OUTPUT AT Q0 E1 V1 &F\13

 2. External modems only: Check that your modem cable has wires for (at least)
    the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals.    If it does
    not, replace the cable with a real modem cable, or (temporarily) configure
    your modem to compensate for the missing signals.

 3. Read your modem manual and check your modem's configuration.  Perhaps its
    interface speed is locked to a different speed than the one Kermit is
    using.  Perhaps Kermit is set to use RTS/CTS flow control, but the modem
    is not asserting CTS.  Also, check its factory and/or saved settings, and
    under what conditions they are restored (for example, are they restored
    when the PC drops DTR?).  How are you selecting saved settings -- read
    your modem manual about (e.g.) the difference between AT&F and AT&F2.  Be
    aware that the AT&Fn commands might not restore all S-registers, so double
    check them.  Be particularly sensitive to the registers that control
    interface speed, modulation technique, error correction, data compression,
    negotiation, and fallback, and note that each modem maker probably uses
    different registers and commands to control each of these features.

 4. Try the following sequence to initialize the port (using COM3 in this
    example):

    SET COM3 <address> <irq>    ; (if necessary)
    SET PORT 3            ; Select port 3
    HANGUP                ; Drop DTR on port 3
    SET PORT 3            ; Re-initialize port 3

 5. SET PARITY NONE when talking to the modem, and then set parity to whatever
    the remote host or service requires after making the connection.  (NOTE:
    MS-DOS Kermit might set its parity to some other value automatically as a
    result of automatic parity detection during file transfer.)

 6. Ensure your PC bus speed is 8MHz.  Some PCs (not PS/2s) come with a BIOS
    SETUP facility that lets you change the PC's bus speed, memory wait
    states, etc.  In general, it is dangerous to deviate from the defaults,
    particularly from the 8MHz bus speed, a standard for add-on devices; it
    might be required by your communication board or internal modem.

 7. Dial at a lower speed.  Make your interface speed match the modulation
    speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc.  Turn off modem
    error correction and compression.  etc etc.  NOTE: connection problems
    between the two modems have nothing to do with Kermit and are beyond the
    scope of this document.  If a modem appears to dial correctly, gets
    connection tones, and then hangs up, it is a problem between the two
    modems (involving one or both modems and/or the phone company), and
    indicates a modem configuration problem, a bug, or a basic incompatibility
    between the calling and answering modems.

 8. The ATZ problem.  If the modem doesn't work after an ATZ command, HANGUP
    and the SET LINE again.  If that doesn't do it, power the modem off and on.

 9. If the modem can't be configured to pass the BREAK signal, but it does
    correctly implement a command for sending BREAK, such as AT\B9, define
    an MS-DOS Kermit macro, SBREAK, to send a BREAK as follows:

      define sbreak pause 1, output +++, pause 1, output ATB\{92}9\13, -
    pause 1, output ATO\13, connect

    and assign it to the key of your choice, for example F1:

      set key \315 {Ksbreak}

10. Call your modem maker's technical support number.  Ask if they have
    replacement chips to fix bugs in your modem.

DISK INTERRUPT CONFLICTS

On certain PCs, Kermit file transfers (or terminal sessions that are being
logged to disk) through serial communication devices (COM1 thru 4) can suffer
from data loss during disk read/write operations.  This is apparently because,
on these PCs, the entire interrupt mechanism is TURNED OFF during disk reads
or writes.  Thus, while the disk driver is active, no interrupts are generated
by incoming characters, and therefore they are likely to be lost (particularly
if the UART does not have its own buffer).

If you experience data loss during uploads (watch the "Retries" counter), try
sending the same file from a RAM disk; if the retries go away, your PC has
this problem.  If downloads to disk have lots of retries, try downloading the
same file to the NUL device (tell MS-DOS Kermit to RECEIVE NUL); same deal.

On some PC's, it has been observed that the disk-interrupt conflict occurs
when using a certain COM port, but not a different one.  For example, on a
PS/2 Model 70 A20, conflicts occur on COM2 but not COM1.

MS-DOS 5.0 AND 6.0

You should not use MS-DOS Kermit (or other communications software) under
DOSSHELL.  Unlike Windows, DesqView, OS/2, etc, DOSSHELL is NOT a multitasking
environment.

MICROSOFT WINDOWS, DESQVIEW, OS/2, ETC.

Although MS-DOS Kermit can work in these environments, and even takes advantage
of many of their features, it does not have a "graphical user interface".  You
still have to type commands to the MS-Kermit> prompt or execute them from
command files with the TAKE command.

OS/2 1.x...

NOTE: The recommended communications software for OS/2 (any version) is
C-Kermit 5A(188) or later, which is a native OS/2 application.

Under OS/2 1.3 and earlier, MS-DOS Kermit only runs in full-screen mode.
Under 1.x of OS/2, the serial port must first be conditioned by the command:

  SETCOM40 COM1=ON

OS/2 2.0 and 2.1...

MS-DOS Kermit can run in a window of OS/2 2.x and, of course, also in a full
screen.  Kermit's flow control has no effect because OS/2 itself is
controlling the device.  You can configure OS/2 to handle flow control itself
by adding a command like the following to your STARTUP.CMD file:

    MODE COM1 XON=ON          (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON  (for RTS/CTS hardware flow control)

If your PC's communication port is a 16550A[FN] UART serial communication
adapter (as is standard on the PS/2), it has a built-in buffer to improve
performance.  To enable use of the 16550's buffering capability, add BUFFER=ON
to your MODE command:

    MODE COM1 XON=ON BUFFER=ON           (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON BUFFER=ON (for RTS/CTS hardware flow control)

If you don't have a buffered UART, MS-DOS Kermit will lose characters galore
at high transmission speeds.

IDLE_SENSITIVITY should be set to 0 and IDLE_DETECTION_TIME should be 100 to
reduce the jerkiness of DOS sessions.

TCP/IP (and presumably other networks supported by MS-DOS Kermit) cannot be
used with OS/2.  OS/2's network interface is totally different from the
methods (such as Packet Drivers) used by DOS.  (You can, however, run MS-DOS
Kermit over packet drivers, etc, if you boot a suitably-equipped DOS from your
A: disk in a DOS window.)

MICROSOFT WINDOWS...

MS-DOS Kermit operates under Microsoft Windows 3.0 and 3.1 in fullscreen mode
on all machines, and in a window on 386-class or higher machines that have
enough memory for Windows to operate in Enhanced Mode (3-4 megabytes are
required).  Be sure to install the KERMIT.PIF file so Windows can can set
things up correctly for Kermit operation.  See the instructions in MSKERM.HLP.

Under Windows 3.x Real or Standard mode, you can use still use MS-DOS Kermit
as a full-screen DOS application.  Kermit works in a window on all PCs (if
they have enough memory) under Windows 2.0.

The use of COM3 and COM4 under Windows is problematic, but most users report
success after finding the right "SET COMx <address> <irq>" command.

When running Kermit in two windows at once, one on COM1, one on COM2, Windows
complains that both applications want to access COM1.  To make sure that COM1's
IRQ 4 is not touched when starting COM2 (part of the "find the IRQ" test),
specify the COM2 port parameters explicitly as SET COM2 \x2f8 3 (standard port
address and IRQ for COM2) to make Kermit skip the test.

Similarly, if you have a serial mouse on COM1, and you want Kermit to use (for
example) COM2 for communication, add the following to your MSCUSTOM.INI
file to prevent Kermit from touching COM1 and interfering with your mouse:

  SET COM2 \x2f8 3 ; (substitute appropriate values)
  SET PORT COM2

Kermit's performance under Windows depends on the BIOS, the machine
architecture, the serial port hardware, which drivers and TSRs are loaded, the
system load, and Windows settings.  A 16550A UART is particularly important
under Windows, as is an effective flow control method. For further tuning,
look at the Windows files SYSIN*.TXT for information about SYSTEM.INI settings
related to communication ports, particularly COMxBuffer and COMBoostTime.

When running MS-DOS Kermit under Windows, specifying a ",P" at the end of a
serial port setting in WIN.INI or in a MODE command can cause loss of
characters from the serial port.  Remove the ",P" from the setting.

See KERMIT.HLP for instructions on using Kermit's TCP/IP support under Windows.

DESQVIEW and DESQVIEW/X ...

Users of DESQview set "Optimize Communications" in the Advanced menu to "No".

DESQview/X reportedly requires that the serial port be configured to
"optimize" to prevent Kermit from losing characters.  Network connections
(TCP/IP over a packet driver or ODI) within an X window of DESQview/X
apparently do not work.

VIDEO PROBLEMS

Kermit does not mix well with NNANSI.SYS, a public domain (or shareware?)
console driver that replaces ANSI.SYS, and which implements "hardware
scrolling", a case of two non-cooperating programs directly manipulating
the video adapter at the same time!  Similar comments apply to other console
drivers that access the screen directly, including ANSI.COM (from PC Magazine,
circa 1988).

To turn off NNANSI.SYS's direct screen access, put the following commands in
your MSCUSTOM.INI file:

  echo \27[=98l                  ; Reset "fast mode"
  define on_exit echo \27[=98h   ; Set "fast mode"

SERIAL COMMUNICATIONS

On PCs with high-quality buffered UARTs, Kermit can be used at speeds up to
57600 bps under DOS (under Windows or DesqView, the maximum speed is probably
lower).     115200 bps works only with a very short shielded cable, and the async
adapters of the two machines in perfect tune.  Some VAX serial port interfaces
are out of tolerance at 19,200 bps and faster.    Some of the new high-speed PCs
(486s like, for example, the IBM PS/VP or the Gateway 2000) come with
unbuffered UARTs.  Despite the speed of the CPUs, these new machines perform
serial communications less reliably than older machines that run at 1/4 the
speed or less, but that have buffered UARTs (like the PS/2-70).

MS-DOS Kermit will tell you whether you have a buffered UART:

  SET PORT 2
  SHOW COMMUNICATIONS
  ...
  COM1 Address: Port \xf38, IRQ 4, 16550A UART FIFO

16550A UART means you have the good kind, FIFO means it has a "First-In
First-Out" buffer.  If Kermit does not say you have a 1655A UART FIFO, and you
are suffering from performance or data loss problems, replace it (if
possible!)  with a 16550A.

If your speed is set too high, the symptom might be lost or garbled characters
or graphics images on the screen, or data-overrun beeps.  Normally flow control
prevents these problems so use it if you can.  Printing while in CONNECT mode
needs flow control to be active.

MS-DOS Kermit does not monitor the communication line for carrier loss during
terminal emulation or file transfer.  You can SHOW MODEM or SHOW COMMUNICATIONS
to inquire about CD, DSR, and CTS.  The script command WAIT permits sensing
carrier presence in a script program.

The SHOW MODEM and WAIT commands work right only if your modem or other
communication device is configured to raise and lower the DSR, CTS, and CD
signals appropriately, and the cable that connects your PC to the modem passes
these signals through.    For some modems, the factory setting is to always keep
CD on, even if there is no connection.    Consult your modem manual.

For serial devices, the HANGUP command (and Ctrl-]H in CONNECT mode) works
only if the cable that connects your PC to the communication device passes the
DTR signal through, and if the communication device itself is configured to
hang up or otherwise terminate the connection when the DTR signal is lowered
by the PC.  For some modems, the factory setting is to ignore DTR transitions.
Consult your modem manual (for example, tell a Hayes modem to "AT&D2").     NOTE:
in version 3.11, the HANGUP command turned off DTR for about 1/2 second and
then turned it back on again.  In version 3.12 and later, the HANGUP command
turns off DTR until the next time you issue a command that accesses the serial
port.  If you can't make the HANGUP command work, define a macro to send a
hangup command to the modem, for example (for Hayes modems):

  DEFINE MYHANGUP PAUSE 1, OUTPUT +++, PAUSE 1, OUTPUT ATH0\13

and then use this macro in place of the regular HANGUP command.

TERMINAL EMULATION

Kermit's VT320/340 emulator lacks the following features:

 . Smooth scroll
 . Downloadable soft fonts
 . ReGis graphics (VT340/330)
 . Dual sessions in split screens (VT340/330)
 . Local screen editing and block transmission (for security reasons)
 . True double height/width characters (these are simulated)
 . Selective erasure (as a character attribute, a formatted screen item)
 . Some of the exotic and rarely-used features of the DEC VT340/330 series:
   formatted screen and graphics operations highly specialized to DEC hardware.

MS-DOS Kermit does not include "ANSI" or "PCTERM" emulation.  If you need
this, as when logging in to a PC-based BBS, make sure you have the ANSI.SYS
(part of DOS) console driver loaded, and then tell MS-DOS Kermit to SET
TERMINAL TYPE NONE, SET PARITY NONE, and SET TERMINAL BYTESIZE 8, and make
sure your PC's code page agrees with what the BBS thinks it is, otherwise
box-drawing characters might come out looking like accented letters. Since
Kermit's own terminal emulator is not active when your terminal type is NONE,
the mode line, screen rollback, similar features are not available.

On certain "national keyboards", like the German one, Kermit's normal escape
character, Ctrl-] (Control-Rightbracket) does not seem work.  This is because
certain control characters are typed differently on these keyboards.  On the
German keyboard, Ctrl-] is produced by holding down the Ctrl (Strg) key and
pressing the + (plus) key.  MS-DOS Kermit has no way of knowing this, and
continues to display the escape character as "^]" in the mode-line help text.

Kermit does not work with certain Swedish keyboard drivers because of a bug in
the keyboard driver.  Workaround: use a different keyboard driver.  Reportedy
there are several different Swedish keyboard drivers available.

Do not attempt to plug an "enhanced" (101) keyboard into a PC/XT or earlier.
The BIOS on early PCs does not support the newer keyboards, even if you
install the corresponding keyboard driver.

If VAX/VMS thinks you have a VT220 or VT320, it sends 8-bit control sequences.
Kermit does not understand them unless you SET TERMINAL BYTESIZE 8.  The
symptom is the appearance of fragments of escape sequences on the screen and
wrong cursor positioning, and possibly fractured tab settings, particularly
during EVE sessions.  You can prevent VMS from sending 8-bit control sequences
(if you really do not have an 8-bit connection) by giving the VMS command SET
TERMINAL /NOEIGHT.  For VAX/VMS, you should also use Xon/Xoff flow control in
both directions (SET TERM /TTSYNC /HOSTSYNC on VMS).

In VT100/200/300 emulation on the IBM PC family, receipt of ESC [ 4 m (turn on
underscore) results in a color change rather than underscore on IBM CGA, EGA
and other color displays.  IBM display adapters have one less attribute than
DEC monochrome terminals, and in addition the two systems intensify dots
differently (IBM does foreground/character dots only, whereas DEC can
illuminate any dot).

SET TERMINAL COLOR 1 [3xx 4xx] (used to make the foreground color bright), if
issued when SET TERMINAL SCREEN REVERSE is in effect, reverts to normal video.

If certain incomplete escape sequences (e.g. Operating System Command) are
received during terminal emulation, Kermit can hang waiting for the string
terminator that never comes, usually because of noise on the communication
line.  Reset the terminal emulator by pressing Alt-= (Alt-equals), the default
key for \Kreset.

Kermit assumes 25 screen lines but can adapt to other lengths if it knows how
to get this information from the video adapter.     There still might be some
confusion about screen length when switching between text and graphics modes,
or between 80 and 132 column mode, or escaping back from CONNECT mode, due
primarily to lack of reliable or consistent information from the many different
kinds of video adapters.

To get properly formatted screens during terminal emulation, be sure to inform
the remote host of your screen width and length.

So that key translation and macros can work on both IBM and non-IBM compatible
PCs, Kermit uses the system BIOS to obtain key scan codes.  But the IBM BIOS
does not produce scan codes at all for certain keys, and may produce duplicate
scan codes for others.    Num Lock, Print Screen, Scroll Lock, and Pause are
examples.

When you PUSH to DOS (including when you use Kermit's RUN command), and you
have XON/XOFF flow control enabled, Kermit sends an XOFF (Ctrl-S) to the host
when you leave, and XON (Ctrl-Q) when you return (if you have RTS/CTS flow
control enabled, Kermit turns off RTS).     This prevents data transmitted by the
host from being lost.  However, if you are using Xon/Xoff and you do this
while using the EMACS text editor on the host, the Ctrl-S will be interpreted
as a Search command, and the Ctrl-Q as a Quote command.     When you return to
EMACS, type several Ctrl-G's to get back to normal.

Similar comments about sending Xoff and Xon apply when Kermit is commanded
to change its screen size between 80 and 132 columns.

Session logging can be turned on using the LOG SESSION command, and it can
be toggled on and off during terminal emulation by using whatever keys are
associated with the verbs \Klogoff and \Klogon.     One user stated the
requirement to enable a session log, but to have it initially turned off.
This can be done as follows (using the F1 and F2 keys as examples):

  SET KEY \315 {\Kloginit}  ; F1 to turn on log
  SET KEY \316 \klogoff        ; F2 to turn log off
  DEFINE loginit log session, set key \315 \klogon, define loginit, connect

To log your session to a printer, add the word PRN after "log session" in
the third line above.

The session log is written to disk by DOS.  The frequency with which DOS
updates this file is governed by the BUFFERS= line in your CONFIG.SYS file (see
your DOS manual).  If you allocate a large number of buffers in CONFIG.SYS,
disk operations occur infrequently and this improves performance.  If you need
to have the session log updated more frequently to minimize the loss of data
when there is a power failure, you can do this (at the expense of efficiency)
by allocating a smaller number of buffers in CONFIG.SYS.

132-COLUMN MODE

If you have a monitor with fixed horizontal frequency but a video adapter that
Kermit knows how to switch into 132 column mode, you will see only garbage on
your screen whenever Kermit switches to 132 columns.  There is no way to tell
Kermit to ignore "switch to 132 columns" commands.  If you buy a
132-column-capable video adapter, be sure you have a compatible monitor.

GRAPHICS TERMINAL EMULATION

In earlier releases, MS-DOS Kermit responded to ESC 1 and ESC 2 for
automatically switching into and out of Tektronix graphics mode, for the
benefit of some long-forgotten host-based graphics software.  This feature
has been discontinued because these escape sequences mean something entirely
different, namely "switch character size" in VT340 Tek mode.

PS/2 Model 25 and 30 MCGA adapter is used in low-resolution CGA mode by
default; images may be elongated or truncated.    Hi-resolution graphics can be
done (as of version 3.11) via SET TERM GRAPHICS VGA, but the PC might not be
able to keep up at speeds above 9600 bps.

When you type the escape character (normally Ctrl-]) while in Tektronix
graphics mode, the screen goes back to text memory.  Then when you type the
argument character, the graphics screen reappears (unless the argument was C or
P).  Ctrl-]F will not file the graphics screen, but rather the text screen,
because that's the screen that's showing after type the Ctrl-] key.  To file
the graphics screen (in TIFF format), use \Kdump (normally on Ctrl-Keypad-End).

You can't dump the Tektronix screen while the GIN-mode crosshair cursor is
active; Kermit's keyboard translator is not active.  Key strokes (of regular
typewriter keys) or mouse actions are used to transmit the crosshair
coordinates.  If you press a non-typewriter key, Kermit just beeps.

Kermit does not emulate a particular kind of color graphics terminal, such as a
DEC ReGIS display or a Tektronix 41xx or 42xx series.  However, it can be used
for color graphics by mixing ANSI color-setting escape sequences with Tektronix
or Sixel commands.  This requires graphics software vendors adding support for
MS-DOS Kermit graphics to their packages (so far, WordPerfect Corp has done
this for their host-resident products).  There is at least one ReGis-to-Sixel
converter on the market: RETOS, a DEC product for VAX/VMS.

Problems may occur when using Kermit with host-resident (VAX/VMS) versions of
WordPerfect because the color palette report sent upon request of WordPerfect
is very long. If the host is not configured properly, parts of the report will
be lost because of overruns on the VMS side.  SET TERM /HOSTSYNC and /TTSYNC
are required for WP/VMS.  Even then intervening communication boxes (e.g.
terminal servers) can become overloaded with the 200++ byte response.

PRINTER SUPPORT

Kermit uses DOS services for printing. There is no knowledge of particular
printer types in Kermit.  Kermit determines whether the printer is ready, or
whether there has been a printing error, via DOS's return code.  If DOS tells
Kermit the printer is not ready, Kermit changes the printer device name to NUL
so subsequent print operations won't block.  To reenable printing operations
(e.g. after turning on the printer, adding paper, etc), use a SET PRINTER
command such as SET PRINTER PRN or SET PRINTER LPT1.

The Print Screen and Shift-PrintScreen keys are never seen by Kermit.  They
are intercepted and acted upon by the BIOS.  Thus Kermit has no control over
the format of the printed output.  For example, a formfeed is not added to the
end to force a page eject.  If you want to print the current screen with a
formfeed at the end, use the following procedure:

  SET DUMP PRN    ; Specify that screen dumps go to the printer

and then use the \Kdump keyboard verb to accomplish the screen dump.  This
verb is assigned by default to the keypad Ctrl-End key, but you can assign it
to another key of your choice (but not Print Screen), for example:

  SET KEY \315 \Kdump  ; Assign screen dump to F1

(Shift-)Printscreen can cause the PC to hang if there is no attached printer.
This is a BIOS feature, Kermit never receives the command.  If this happens
during terminal emulation, try pressing Alt-= (hold down Alt and press the "="
key) several times to reset the terminal emulator.

Serial printers are not well supported by DOS, and since Kermit does all its
printing through DOS, Kermit's printing features might not work well with
serial printers.  To use a serial printer effectively, you must have a driver
for it that takes care of flow control, such as MSPSPD, available on the
MS-DOS Kermit Utilities and Technical Documentation diskette.

Transparent printing starts when the host sends the sequence ESC [ 4 i and
stops when the host sends ESC [ 5 i.  All characters, including escape
sequences, that arrive at the port are passed directly to the printer without
translation (but the parity bit is stripped if Kermit's parity is not NONE).
If character translation is desired, or it is desired not pass screen-control
escape sequences to the printer, use Autoprint rather than Transparent print
(ESC [ 0 i, ESC [ ? 4 i, ESC [ ? 5 i).    In that case, characters are translated
to the current IBM code page.  If your printer doesn't support your IBM code
page, you need an external utility to translate from the PC code page to the
printer's character set.  You can use SET PRINTER xxxx to capture Transparent
print or Autoprint data into a file.

INTERNATIONAL CHARACTER SETS

MS-DOS Kermit does not directly support Cyrillic terminal sets; that is, you
can't set your TERMINAL CHARACTER-SET to a Cyrillic set.  However, you can
still have a Cyrillic terminal session if you have a Cyrillic code page loaded
and you have issued the appropriate collection of SET KEY and SET TRANSLATE
INPUT commands (see the CYRILLIC directory on the distribution diskette).

MS-DOS Kermit does not support Japanese Kanji character-set translation during
terminal emulation.  However, version 3.13 does support the Kanji video mode
used on IBM-compatible DOS/V PCs, which allows Kanji terminal emulation if
the remote character set happens to be Shift-JIS (CP982).

Character-set translation during terminal emulation is done between the remote
TERMINAL CHARACTER-SET and the PC's current code page. During file transfer,
it's between the TRANSFER CHARACTER-SET and the PC's code page.  At startup,
MS-DOS Kermit asks DOS to report the current code page, and it sets your FILE
CHARACTER-SET and your TERMINAL CODE-PAGE to this value.  But DOS often lies
about the code page, so in most cases when your actual code page is anything
but 437 (or maybe 850), you, yourself, will have to tell MS-DOS Kermit what
your code page *really* is, using the following two commands:

  SET TERMINAL CODE-PAGE CPnnn ; Your actual current code page.
  SET FILE CHARACTER-SET CPnnn ; The code page for incoming text files.

The two would normally be the same, but MS-DOS Kermit lets you set them
differently if you want to, for example if you have a Hebrew code page loaded
for display purposes, but you want to download a Russian file that you will
display later, after loading a Cyrillic code page.

MS-DOS Kermit does not allow all possible combinations of FILE and TRANSFER
character sets.     The Hebrew code page (CP862) forces the Hebrew transfer
character set, and vice-versa.    Similarly for Cyrillic and Latin-2, etc.
Latin-1, however, can be used with many code pages: 437, 850, 861, 863, 865.

Some of the ISO 2022 or DEC-specific character-set designation escape
sequences, which *do* work correctly, nevertheless fail to have an effect on
the character-set field of the SHOW TERMINAL display.

LOG SESSION records characters that arrive at the serial port, before
translation by either Kermit's built-in terminal character set translation
tables or by user-specified SET TRANSLATION INPUT commands.  This allows
REPLAY to work correctly but it prevents special characters from being logged
after translation to the PC's own character set.  Screen dump (Ctrl-End or
Ctrl-]F) and autoprint, however, record the translated characters.

SET TERMINAL CHARACTER SET is effective only for text screens, not for
graphics screens.  This is because the fonts for all the special characters
have not been designed yet (and may never be, and even if they are, they would
require a lot of memory).

International characters in macro names are not case independent.

Case-independent string matching operations (e.g. SET INPUT CASE IGNORE,
IF EQUAL xxx yyy) won't necessarily work with international characters.

COMMAND PROCESSING

When a command field begins with the @ (at-sign) character, the following
characters are interpreted as a filename that contains the rest of the
command.  If you need to type a command field that actually starts with @, or
respond to an ASK or ASKQ query with text that starts with an atsign, you have
to encode the atsign as \64 or \{64}.

\B in an OUTPUT command tells Kermit to send a BREAK.  \L Tells Kermit to
send a Long BREAK.  If you need to output \B or \L literally, use two OUTPUT
statements, e.g.:

  define xbreak pause 1, output +++, pause 1, output AT\92, output B, -
    pause 1, output ATO\13, connect
  set key <key-of-your-choice> {\Kxbreak}

Notice that the backslash itself is written as "\92" to output it literally.

Certain commands, such as RUN, DIRECTORY, TYPE, etc, invoke COMMAND.COM
"underneath" Kermit, and COMMAND.COM might, in turn, invoke other programs.
If you get the message "Can't run program" in response to such a command, it
usually means there is not enough memory.  But you should also check your
SHELL environment variable.

If you include the word STAY anywhere on the Kermit command line, e.g.:

  kermit echo stay

it is interpreted as a STAY command.

A command file that contains lines or commands too long for DOS's line buffer
(usually 128 characters) can hang your PC: a DOS problem, not a Kermit problem.

Commands in command files can be continued by including "-" as the last
character on the line, but NOT if the line ends with a trailing comment.  In
other words, you can't have a trailing comment on a continued line. If you
need to end a line with a dash, but the dash is part of the command rather
than a continuation symbol, use \45 instead or add a trailing comment.

Trailing comments can be used only in command files.  All text starting with
the first semicolon through the end of line is ignored.     If you need to include
an actual semicolon in a command, precede it with a backslash (\;).

The name and password that you specify in SET SERVER LOGIN must be matched
exactly by the ones in REMOTE LOGIN.  Case matters.  If you need to include
spaces within the username, password, or account field of the REMOTE LOGIN or
SET SERVER LOGIN commands, surround the field with {braces}.

DISABLE ALL is not equivalent to all the other DISABLE commands given
separately.  For example, DISABLE DELETE restricts REMOTE DELETE commands from
the client to working only in the MS-DOS Kermit server's current directory,
while DISABLE ALL prevents all types of modifications to the PC's file system,
including file deletion and creation.

KEY MACROS

Key macros are executed while in CONNECT mode. If you assign the \Khangup verb
to a key, Kermit remains in CONNECT mode after the hangup takes place.  On a
serial dialup connection, Kermit turns off the DTR signal, and you should see
a confirmation message from the modem, such as NO CARRIER, on your screen.  On
a TCP/IP network connection, however, Kermit does indeed drop the connection,
but since Kermit is still in CONNECT mode, it is immediately reestablished.
If you want to terminate a network session by pressing a key, use a method
that leaves CONNECT mode.  You can do this by defining a macro to hang up, and
then assigning execution of the macro to the key, e.g. Alt-d:

  define xxx hangup
  set key \2336 {\Kxxx}

This causes Kermit to return from CONNECT mode and execute the macro without
returning to CONNECT mode.  This technique works for both serial and network
connections.

To assign several verbs to a single key, use braces as in this example:

  set key \315 {\{Kgold}\{KdecF13}}

or this:

  set key \315 {\{Kfoo}\{Kdump}\{Kbar}}

in which "foo" and "bar" are macro names, and \Kdump is Kermit's screen-dump
verb.

FILE TRANSFER

SET EOF CTRL-Z, when used with text files that actually contain Ctrl-Zs, might
result in gaps or truncation in the vicinity of the Ctrl-Z.  This is a DOS
"feature".

When using Kermit through a terminal server (particularly those that execute
the TCP/IP Telnet protocol), or directly through a SET PORT TCP connection, it
is sometimes necessary to SET PARITY SPACE for file transfer. It is sometimes
impossible to use very long packets with terminal servers.  Try SET RECEIVE
PACKET-LENGTH 80, working up or down to the longest length that works.

REMOTE TYPE and other REMOTE commands resulting in an error "Unable to open
CON": insufficient FILES= in CONFIG.SYS.  FILES= should be at least 20.

MS-DOS Kermit uses the program named in the DOS Environment command line
starting as SHELL= as a replacement for COMMAND.COM.  Such a line is seen by
typing SET at the DOS prompt, and it is not associated with the SHELL= line
appearing in file CONFIG.SYS.

The MS-DOS Kermit command REMOTE SET BLOCK-CHECK will generally have no effect
upon a remote server unless the SET BLOCK-CHECK is also given locally to
MS-DOS Kermit.

The host prompt for TRANSMIT is a single character (SET TRANSMIT PROMPT).  It
is not possible to specify a multi-character or varying transmit-prompt.

SCRIPT PROGRAMMING

The terminal emulator is not active during execution of script commands such
as INPUT and OUTPUT.  This means:

 1. If the host sends the escape sequence that tells the terminal to identify
    itself, it is ignored.  You have to put the appropriate INPUT and OUTPUT
    commands in your script program.  Here is a macro to set your terminal type
    in Kermit and to set up the appropriate response string as well as terminal
    type string:

    def term if not def \%1 def \%1 vt320,-
     set term type \%1,-
     if error end 1,-
     assign _ttype \%1,-
     if eq \%1 vt320 assi _tid \27[\{63}63\;1\;2\;4\;8\;9\;15c,-
     if eq \%1 vt220 assi _tid \27[\{63}\62\;1\;2\;4\;8\;9\;15c,-
     if eq \%1 vt102 assi _tid \27[\63\;6c,-
     if eq \%1 vt100 assi _tid \27[\63\;1c,-
     if eq \%1 vt52  assi _tid \27/Z

    Whenever you switch terminal emulations, do "term vt102" instead of "set
    term type vt102" (substitute your preferred terminal type).     In any script
    that responds to ESC Z (or whatever), have it "output \m(_tid)", and any
    prompt that asks for your terminal type you can "output \m(_ttype)".  And
    be sure to execute a "term" command in your MSKERMIT.INI file, so your
    initial terminal type is set.

 2. A host-generated escape to put the terminal in Tektronix mode has no
    effect.  Put explicit SET TERMINAL TYPE TEK commands in the appropriate
    places in your script program.

 3. Screen formatting escape sequences have no effect.    If you have SET INPUT
    ECHO ON, they are simply displayed as-is.

If the remote host is sending ANSI (VTxxx) escape sequences during execution of
the script program, then users of IBM PCs can use the ANSI.SYS or similar
console driver to interpret the escape sequences.  This is particularly useful
when running a script that logs in to a full-screen system, such as an IBM
mainframe through a protocol converter.     But beware: ANSI.SYS is not totally
compatible with Kermit's VT emulator, and it may produce unwanted side effects,
the most annoying of which is suddenly popping your PC into 40-column mode!  If
you experience difficulties with your screen display while using Kermit script
programs, use SET INPUT ECHO OFF.  Or remove ANSI.SYS from your CONFIG.SYS file
and reboot.

PAUSE, WAIT, and similar commands also cause port input to be echoed to the
screen if INPUT ECHO is ON.  Use SET INPUT ECHO OFF to defeat this effect.

If the REINPUT command fails to find the requested text in the INPUT command
buffer, it will wait (up to the timeout interval) for more characters to
arrive from the communication channel.

INPUT / REINPUT combinations will not work if the INPUT buffer is smaller than
the amount of text that separates the INPUT text from the REINPUT text.  You
can increase the size of the INPUT buffer by including the desired size in
your KERMIT=INPUT <size> environment variable.  The default size is 256 bytes.

Script programming hint: To test whether a readable floppy disk is available
in drive A:, do this:

  SPACE A:
  IF FAILURE ECHO No diskette in drive A:.

The ON_EXIT macro is intended only for automatic execution when MS-DOS Kermit
exits.  It only works once, to prevent recursion (as would happen, for
example, if you put an EXIT command in your ON_EXIT definition).

MEMORY MANAGEMENT

MS-DOS Kermit, like any DOS or Windows program, is likely to misbehave if your
PC memory is insufficient or is incorrectly configured.  MS-DOS Kermit runs in
conventional memory (the first 640K) of your PC.  It occupies about 280K
initially, and then allocates additional memory as needed for rollback
screens, file-transfer packet buffers, etc.  Kermit uses additional memory to
execute certain commands such as TYPE and DIRECTORY, for which it invokes a
second copy of COMMAND.COM (appoximately 30K) in conventional memory, as well
as RUN, which can invoke not only COMMAND.COM, but an additional program to be
run by COMMAND.COM, for example "run edit".  If there is insufficient memory,
these operations will not work; thus it is always best to have as much free
conventional memory as possible.

Memory for file-transfer packets is allocated at the time the transfer begins,
based on the current sliding-window size (SET WINDOW) and packet-length (SET
RECEIVE PACKET-LENGTH), and is deallocated when the transfer ends.  So SHOW
MEMORY won't reveal the effect of the packet buffers.  If insufficient memory
is available for the requested window size and packet length, MS-DOS Kermit
automatically reduces its RECEIVE PACKET-LENGTH.  Conventional memory is
always used for packet buffers. Thus packet buffers and RUN/PUSH/TYPE/
DIRECTORY commands "time-share" the same conventional memory.

Memory for graphics screens is taken from your video display adapter.  Storage
of graphics images in the video adapter's on-board memory allows rapid
switching between text and graphics screens provided (a) your video has
sufficient memory, (b) the memory is not "mapped away", and (c) you are not
running Kermit under Windows.

Memory for rollback screens is allocated when the CONNECT command is first
given, i.e. when Kermit first displays its terminal emulation window, and
remains allocated until you EXIT from Kermit.  This can be demonstrated by
starting Kermit, giving the command SHOW MEMORY, then giving the CONNECT
command, then escaping back (Alt-x), and then giving the SHOW MEMORY command
again -- see how available memory has shrunk.  Approximately 4K is required
per 24x80 rollback screen (more for bigger screens).  The default number of
rollback screens is 10, but the number can be set to practically any value at
all (0 or greater) by giving the following command to DOS before you start
Kermit (interactively, or in your AUTOEXEC.BAT file):

  SET KERMIT=ROLLBACK 40

The smaller the number, the less memory required; the bigger, the more memory.
In version 3.13, you can also give the new command:

  SET ROLLBACK <number-of-screens>

at the MS-Kermit prompt at any time, and the rollback memory will be adjusted
when you next CONNECT.

A large number of rollback screens can crowd out other possibilities, like the
ability to use Kermit's RUN, PUSH, TYPE, DIRECTORY, and other commands that
run inferior processes.  Version 3.13 of MS-DOS Kermit lets you store your
rollback screens in Expanded Memory (EMS) if you have more than 1MB of
physical memory and you have an expanded memory manager for it like
Quarterdeck QEMM or EMM386 and HIMEM that come with DOS 5.0 and Windows 3.1.

Using expanded memory for rollback screens frees 40K of conventional memory if
you are using the default number (10) of rollback screens, and it also allows
you to have a much larger number of rollback screens.  The following steps are
required to keep your rollback screens in expanded memory:

1. Make sure the desired amount of expanded (EMS) (not "extended", or XMS)
   memory is available.     The DOS MEM command will tell you this.

2. In your AUTOEXEC.BAT file, set the desired number of Kermit rollback
   screens.  For example, for 250 screens (requiring about 1 megabyte):

      SET KERMIT=ROLLBACK 250

3. Give the following command to MS-DOS Kermit:

      SET TERMINAL EXPANDED-MEMORY ON

   If this command fails, Kermit prints an appropriate error message.

Now start a Kermit session, scroll some text off the screen during CONNECT
mode, and check the operation of the PageUp/PageDown keys.  If they work,
you're done.  And as an added benefit, graphics screens will also be stored
in expanded memory, allowing you to switch between graphics and text screens
(Alt-minus), even under Windows, without losing the graphics screen.

If it doesn't work, then welcome to the bewildering world of DOS memory
management.  The most common symptom of a bad memory configuration is that
your PC will freeze the first time Kermit tries to scroll a line off the
screen or the first time it tries to clear the screen.    Now you should begin
looking at your CONFIG.SYS file.

First, here is a straightforward DOS 5.0 CONFIG.SYS configuration that sets up
a PC with 8MB of memory to have 6MB of expanded memory:

  DEVICE=C:\DOS\HIMEM.SYS
  DEVICE=C:\DOS\EMM386.EXE 6144 RAM
  DOS=HIGH,UMB
  DEVICEHIGH=C:\DOS\ANSI.SYS

HIMEM.SYS must be loaded first and then EMM386.     With memory management now
active, DOS is told to use "high memory" (don't ask) and "upper memory blocks"
(UMB, the space between 640K and 1MB) and then ANSI.SYS is loaded into the
upper memory area rather than conventional memory.

EMM386 is asked to take care of 6144K of expanded (EMS) (not extended, XMS)
memory, and the RAM switch means that it also should manage the upper memory
blocks.     This configuration works on a PC that has 8MB of memory (6144K = 6MB
= 1024 x 6), leaving 1MB of extended memory for any process that might need
it.  If you have less memory than that, adjust as appropriate.

If you are using RAMDRIVE.SYS, give it the /A switch to use expAnded memory,
rather than the /E switch for extEnded memory, e.g.:

  DEVICEHIGH=C:\WINDOWS\RAMDRIVE.SYS 1024 512 64 /A

After making these changes to CONFIG.SYS, reboot your PC and give a DOS MEM
command to check that the needed amount of Expanded (EMS) memory is available.

Now run Kermit and check the expanded-memory rollback feature. Also tell
Kermit to SHOW MEMORY to see how much conventional memory remains after
starting Kermit.  If it's not enough for your purposes, look at your
CONFIG.SYS and AUTOEXEC.BAT files to see if there are any other drivers or
TSRs that can be removed or loaded high.  Here's another hint: If you access a
CD-ROM drive via Microsoft CD Extensions, include the /E switch (Expanded)
when you start it up:

  C:\BIN\MSCDEX /E /D:MSCD000 /M:10

In a more complicated configuration, suppose you have a network interface
board that uses a certain segment of memory (at, for example, segment address
CC00) which conflicts with DOS's memory management (note: addresses are
usually written in hexadecimal).  In that case, you have to tell EMM386 to
"exclude" this segment from its memory managing:

  DEVICE=C:\DOS\EMM386.EXE 6144 x=cc00-cc7f RAM

These segment address numbers are obtained from the technical manual for your
network interface board (or, perhaps more likely, from the board vendor's
technical support phone number).  Additional "exclude" clauses might be
needed for other boards or adapters.

For debugging, get additional information about your PC's memory layout using
the DOS MEM/C and MEM/P commands, the MSD program that comes with Microsoft
Windows, or the MFT (Manifest) program that comes with Quarterdeck QEMM.

If all else fails, tell Kermit to SET TERMINAL EXPANDED-MEMORY OFF (this is
the default anyway).  NOTE: whenever you switch Kermit's expanded memory
status from OFF to ON or vice versa, your previous rollback screens are lost.

Use caution with QEMM v6 "Stealth (ST:M) optimization".     This prevents Kermit
from accessing your video board's BIOS memory and finding the video board's
signature, and therefore from determining the appropriate method for switching
between 80 and 132 columns.  Most boards have a signature string within the
first 200h bytes of the video BIOS and excluding that much from stealth mode
should be sufficient to preserve the identification information.

HARDWARE-RELATED PROBLEMS

Many of the newer low-cost, high-speed clone PCs suffer from noisy buses,
interrupt or address conflicts, and other maladies not seen on earlier, more
expensive (but slower) models.

INTERACTIONS WITH DOS

A REMOTE HOST or similar command sent to an MS-DOS Kermit server can invoke the
DOS critical error handler, which issues its familiar "Abort, Ignore, Retry?"
message on its real screen, and is waiting for a response from its own real
keyboard, and so the server will no longer respond.  Kermit attempts to catch
many of these errors before DOS learns learns about them, but some cannot be
avoided (like disk i/o errors).

Similarly, a REMOTE DIRECTORY command sent to an MS-DOS Kermit server can
cause the server to hang if its default directory command pauses after each
screen (DIRCMD=/P).  In fact, the server will hang any time a subprocess
invoked by any REMOTE command (watch out, in particular, for REMOTE HOST)
requests keyboard input.

Interaction between MS-DOS Kermit and various terminate-and-stay-resident
(TSR) programs is necessarily unpredictable.  Console, mouse, clock, or
graphics drivers might interfere with file transfer, e.g. the CMOSCLK.SYS
driver on the PS/2 model 55SX.  If TSR programs are interfering with Kermit
(by taking over the timer or serial port interrupts), you should remove them
all from your AUTOEXEC.BAT or CONFIG.SYS files, and then put them back one by
one until you have identified the culprit.

Use caution when invoking certain TSR programs while PUSHed from Kermit
(e.g. using the PRINT command for the first time), as not all of these
programs observe proper etiquette for allocating and freeing memory, and the
TSRs will be loaded above Kermit into the middle of memory where they may
prevent large programs from loading later.

NETWORKS

When communicating across certain network pathways, the longest burst of
information tolerated from the PC can be rather short. For example, the LAT
path with SET PORT DECNET (PATHWORKS) has a limit of 256 bytes and the SET
PORT TES path has a limit of 512 bytes in a burst (or less, depending on the
TES release).  Longer bursts can cause the network software on one end or the
other to drop the connection.  This is most likely in the following situations:

 1. During file transfer, when sending files from the PC using long packets
    and/or sliding windows.  The total size of the packets in the window
    (packet length times the number of window slots) must be less than the
    burst limit for the network.

 2. During VT320 terminal emulation, if the host application (such as VMS
    or UNIX WordPerfect) sends a Terminal State or Color Palette Request
    escape sequence, DECRQTSR, "ESC [ 2 ; 2 $ u".  The response to this
    request is more than 200 characters long and has been known to break
    LAT and TES connections.

This is not a Kermit problem, but rather a limitation (or bug) in the
underlying networking method.  Workarounds include:

 1. If you have a DECnet LAT connection, make a DECnet CTERM connection
    instead (i.e. unload your LAT TSR and load the CTERM TSR instead).

 2. Enable RTS/CTS flow control between MS-DOS Kermit and the device it is
    most immediately connected to, if possible.     Otherwise, enable Xon/Xoff
    flow control in MS-DOS Kermit and at the host on the far end (e.g. tell
    VMS to SET TERM/HOSTSYNC/TTSYNC).

 3. Use a different networking method, e.g. TCP/IP instead of DECnet.

Sending BREAK over network connections via SET PORT BIOS1 + Int 14h
interceptor may or may not work, depending upon the actual network and drivers
in use.     Kermit uses the BREAK facility if the driver and network support it.

Symptom: PC no longer works after installing a network board.  Diagnosis: a
16-bit VGA display adapter is running in 16-bit mode.  Cure: Jumper it back to
8 bits and all should start working again.

PC-NFS prevents applications programs such as Kermit from creating a file in
the root directory of a PC-NFS disk drive.  When the applications program asks
if a particular file exists in the root, PC-NFS always responds with "volume
label present", whether or not the actual file is present.

SET PORT TELAPI performance is good with version 4 of Novell's LAN WorkPlace
for DOS but it is poor with version 3.5 because that older version sends each
Kermit byte in an individual packet.  Because the TELAPI interface lacks the
ability to resolve Internet, names you can use the small Kermit macro below to
invoke Novell's program TSU to resolve names and set up a session:

  define telapi run tsu -o \%1 k1,run tsu -a k1 1,set port bios1

Use as Kermit command "telapi my.favorite.host" followed by CONNECT.  This
tells TSU to "o"pen a connection to the host named in Kermit variable \%1 and
give the session a TSU tag of "k1".  Then run TSU again and "a"ttach this
session to COM"1" meaning Kermit's BIOS1 port.    Four sessions can be started
by choosing different tags and port numbers, though this macro does not make
the changes.  An alternative to SET PORT BIOS1 is SET PORT 3COM for much
faster throughput; an end-of-session signal is not available with this method
so the user must exit manually.

You can't run LAN Workplace for DOS (LWP) and make SET PORT TCP/IP connections
with Kermit at the same time, because only one protocol stack of a given kind
can run over a single network board.  If you want to make a TCP/IP connection
with Kermit when LWP is loaded you can either (a) use SET PORT TELAPI rather
than SET PORT TCP/IP (slower and less flexible), or (b) unload LWP from the
DOS prompt by typing TCPIP UNLOAD, and then start Kermit.

The Interconnections TES product, which Kermit fully supports, has a fancy
menu that pops up if you type the TES "hot key", Alt-LeftShift-T.  Reportedly,
this pop-up menu interferes with the LK250 driver that is distributed with
Kermit (it works fine with regular IBM keyboards).  The LK250 driver uses a
special interrupt, and the TES menu program might not properly chain this
interrupt.  The workaround is to use TES's text-mode menu, which Kermit brings
up if you type Alt-Home during terminal emulation.  Version 3.13 of MS-DOS
Kermit transparently supports both older and the latest TES products.

For DECnet/DOS (PATHWORKS) LAT connections, it is often necessary to tell the
LAT control program on the PC to reserve enough memory for all of the local LAT
host names.  By default, space for 16 names is allocated.  Increase your LAT
control program's memory allocation if you have more than 16 hosts on your
DECnet network.     Also, remove ALL permanent LAT names from your database and
let the network provide them (this can mean waiting a minute or two for all
broadcasts to be heard).

Reportedly, when making NETBIOS or 3COM(BAPI) connections under Windows,
characters from a DOS window can show up in the Kermit window.  Reportedly,
this can be fixed by setting Kermit's foreground and background priority to
150 and setting the priority of the other DOS applications to 5000.

NETBIOS STATION-TO-STATION CONNECTIONS

The procedure for establishing a NETBIOS PC-to-PC connection is as follows:

 1. On the first PC:
      SET NETBIOS NAME <xxx>
      SET PORT NETBIOS
      SERVER

 2. On the second PC:
      SET PORT NETBIOS <xxx>.K

(<xxx> is any name you choose, up to 14 characters long.)

Now you can initiate file transfer and other Kermit protocol operations from
the second PC.    If you want the two PCs to "chat" in terminal mode, send a
FINISH command from the second PC (or type Ctrl-C on the first, server, PC),
and then give the following commands to both PCs:

  SET TERMINAL NEWLINE ON
  SET LOCAL-ECHO ON
  CONNECT


TCP/IP SUPPORT

As of version 3.11, MS-DOS Kermit contains built-in TCP/IP and TELNET protocol
support.  This allows a PC equipped with an Ethernet or other network board
that is connected to a TCP/IP network to communicate with any other node on
the network, without requiring any additional TCP/IP software on your PC.  You
need an external Ethernet-style (Class 1) packet driver for your network
interface board, or (as of version 3.12) a SLIP Packet Driver or a Novell ODI
driver, or (as of version 3.13) the Novell SLIP_PPP ODI driver.     You can also
use any of various "shims" to sit between Kermit and other kinds of board
drivers (e.g. NDIS) to make them look to Kermit like Ethernet packet drivers.

With ODI, Kermit's Telnet operates across Ethernet (many frame kinds), Token
Ring, Arcnet, and PCnet.  Kermit does not contain built-in network device
drivers.  Packet drivers are available from network interface manufacturers,
and via anonymous FTP from Columbia University, host watsun.cc.columbia.edu
[128.59.39.2], cd packet-drivers, get the READ.ME file, read it, and take it
from there.  These files, now called the Crynwr packet driver collection, are
also available from Columbia University via mail order.     ODI drivers are
available from makers of the LAN adapter and in some cases from Novell.     See
Novell archive "novlib" on CompuServe and on machines ftp.is.sandy.novell.com
[137.65.12.2] and mirrors such as netlab2.usu.edu [129.123.1.44] for Novell
supplied ODI drivers.

The TCP/IP code in this version of Kermit has been tested successfully with at
least the following boards and packet drivers (according to reports from
users):

  Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1
  3COM 3C501 with Clarkson 3C501 packet driver 5.0.
  3COM 3C503 with Clarkson 3C503 packet driver 9.4.0.
  Western Digital WD8003E with Crynwr (not WD) WD8003E packet driver 9.7.0
  Cabletron 2000 and 3000 series DNI boards with CSIPD_E 1.0x and later packet
    drivers on unshielded twisted pair, thin Ethernet, and thick Ethernet,
    on both PC/AT and Microchannel buses.
  Micom-Racal NI5210 with NI5210 packet driver.
  AT&T EN100 with Clarkson AT&T packet driver.
  IBMTOKEN.COM 3C501 emulation packet driver 1.9 over various Token Ring
    boards and drivers.
  DIS_PKT over NDIS for LAN Manager networks and NDIS-compliant boards
    including SD8003, 3C503, AT&T 10MB/sec thinwire
  Harvard ODIPKT over LSL, LANSUP, and IPXODI over Ethernet (but not
    Token Ring)
  Novell NE2000 with Crynwr NE2000 packet driver (not the Novell MLID!)

Token Ring, Arcnet, and LocalTalk packet drivers are not supported, as they
are not Ethernet- or SLIP-class Packet drivers.

The performance of the 3C50x packet drivers is poor, but the operation seems
correct.  Suggestion from a 3COM 3C503 Ethernet board user: "When installing
the packet driver for 3Com 503 cards, one has to pay attention that the memory
option on the card is not disabled.  It was in my case, and the packet-driver
did not complain.  Since other drivers (e.g.  the DEC PATHWORKS driver) do not
require the memory enabled, the default is disabled."

Reportedly, the packet driver supplied by Western Digital with their WD8003E
and/or Elite network boards cannot be found by Kermit.    The Crynwr WD8003E
packet driver, however, works correctly with both the WD8003E and Elite boards.
Same comments apply to WD8003E.SYS shipped with PC-NFS.

To reconfigure a Novell network (NetWare 3.xx or earlier) for packet drivers
so Kermit and Novell software can be used concurrently, use software from
Brigham Young University, available via anonymous ftp from dcsprod.byu.edu.
For further information, read the Kermit Distribution file MSABYU.HLP.

An Ethernet-simulation packet driver "shim" is available for systems using the
NDIS (Network Driver Interface Specification) program.    NDIS is frequently
used with LAN Manager networks, including AT&T's StarGROUP network and DEC's
Pathworks for DOS.  The interface program is named DIS_PKT and originated with
FTP Software Inc.  Their program DIS_PKT.GUP is available by anonymous ftp to
vax.ftp.com, and a research version DIS_PKT9.ZIP is available from Utah State
University by anonymous ftp to netlab2.usu.edu.     Instructions for configuring
Lan Manager to include DIS_PKT are included with the program.  (Also available
from watsun.cc.columbia.edu, in the packet-drivers.new directory and on the
MS-DOS Kermit diskette.)

Here is a setup with which one user reports success in using MS-DOS Kermit's
built-in TCP/IP support with LAN Manager and a Novell NE2000 Ethernet board:

CONFIG.SYS
---------------------------
SHELL=C:\COMMAND.COM /P /E:1024
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE noems I=B000-B7FF i=e000-efff
DOS=HIGH,UMB
COUNTRY=61,,C:\DOS\COUNTRY.SYS
BUFFERS=13
FILES=50
STACKS=0,0
LASTDRIVE=Z
DEVICEHIGH=C:\DOS\ANSI.SYS
DEVICEHIGH=C:\WINDOWS\MOUSE.SYS
DEVICEHIGH=C:\LANMAN\DRIVERS\PROTMAN\PROTMAN.DOS /i:C:\LANMAN
DEVICEHIGH=C:\LANMAN\DRIVERS\ETHERNET\NE2000\NE2000.DOS
DEVICEHIGH=C:\KERMIT\DIS_PKT9.DOS

PROTOCOL.INI
----------------------------
[PROTMAN]
  DRIVERNAME = PROTMAN$
  DYNAMIC = YES
  PRIORITY = NETBEUI

[PKTDRV]
; This section added for kermit
  DRIVERNAME = PKTDRV$
  BINDINGS = NE2000_NIF
  INTVEC = 0x65

[NETBEUI_XIF]
  DRIVERNAME = NETBEUI$
  SESSIONS = 8
  NCBS = 12
  BINDINGS = "NE2000_NIF"
  LANABASE = 0

[NE2000_NIF]
; protocol.ini section for the Novell NE2000 Card
  IOBASE = 0x300
  INTERRUPT = 5
  DRIVERNAME = MS2000$

Kermit's TCP/IP support does not work over the Harvard ODIPKT driver on a Token
Ring network because it requires Kermit to use Token Ring rather than Ethernet
frames (but it does work with ODIPKT over Ethernet).  Version 3.12 and later
support ODI directly; ODIPKT is not necessary except when using Windows.

Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of
Ethernet frames: DIX/Blue-Book/Ethernet_II, 802.2, 802.2 with SNAP, and 802.3,
as well as with Token Ring, Arcnet, and PCLan broadband.  No extra protocol
"shim" is needed, but you must have the ODI drivers which come from Novell or
from your network board vendor.

The ODI interface will be tried if a Packet Driver is not found, and it can be
selected in preference to a packet driver by the command:

   SET TCP/IP PACKET-DRIVER-INTERRUPT ODI

where "ODI" replaces the interrupt number of a Packet Driver.

For ODI, the file NET.CFG should have the lines "Protocol IP etc" similar to
the example below:

    # File NET.CFG, example
    PB buffers=10
    show dots=on

    Link Support
        buffers 6 1514
        MemPool 2048

    Link Driver SMCPLUS
        Port  280 20
        Mem   000CA000 2000/10
        Int   7
        frame Ethernet_II
        Protocol IPX    8137    Ethernet_II
        Protocol IP    0800    Ethernet_II
        Protocol ARP    0806    Ethernet_II
        Protocol RARP    8035    Ethernet_II

To make TCP/IP connections, Kermit requires three "protocols", IP, ARP, and
optionally RARP as shown above.     The frame kinds can be anything the board
will support: Ethernet, Token Ring, Arcnet, all IEEE 802.2-based frames etc.
ODI will complain if the frame type cannot support these protocols.  Arcnet
uses different TYPE values, D4 for IP, D5 for ARP, and D6 for RARP, rather
than 0800 etc, as per RFC-1201.

Which board Kermit (or IPX or other application) will use if two or more
boards are available?  Although one would think the board could be selected by
placing the Protocol IP, etc, lines under the desired Link Driver section,
such is not really the case; those lines tell LSL the frame kind to associate
with the protocol (say IP) but not the board.  The frame lines are associated
with particular boards, however.  The default method for finding a board is
that the application chooses "the first board" offering a suitable frame,
regardless of whether or not the Protocol IP, etc, lines are present for that
board.  "First" refers not to the contents of NET.CFG but to the order in
which board drivers are loaded at DOS level.  So the indented protocol lines
tell ODI which frame a protocol needs, and a TYPE to use for recognizing
packets, but the lines do not identify a particular board.

To target a particular board a separate main section is used in NET.CFG.  The
section starts with the word Protocol against the left margin and has Bind
indented beneath it, like this -

    Protocol Kermit            Identifies Kermit section of NET.CFG
        bind SMCPLUS        Bind to SMCPLUS board driver

When a board name is used more than once then the alternative form is to use
a board number in place of the name:

    Protocol Kermit
        bind #2            bind to the board loaded second

Kermit considers the text in these sections to be case-insensitive.  The
#<digit> construction must not have a separation between the number sign (#)
and the digit.    The #<digit> case is normally used when two or more boards
share the same driver and thus are not distinguishable by name alone.

A sample STARTNET.BAT file might look like this:

@echo off            run quietly
c:\lsl >nul            LSL is always loaded before boards
c:\smcplus.com >nul        SMC/WD8003E board, the first
c:\exos.com >nul        EXOS-205T board, the second
rem c:\odinsup            Odinsup can coexist with Kermit
rem c:\odipkt 0 96        Odipkt can coexist with Kermit
c:\ipxodi >nul            IPX is always loaded after boards
rem echo Starting network...    may be needed to help some drivers
c:\bnetx ps=my-preferred-server > nul
rem (Packet Burst mode)    NETX loads after IPX
@echo on

If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the
first loaded board, SMCPLUS, in the absence of a "bind" command.  Putting the
section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG
selects a particular board for Kermit.    A complete NET.CFG file using two
boards is shown below and applies to both regular NetWare shells and the
newer VLM shells (but with minor changes to the no-board parts of things).

# File NET.CFG, an example with two boards
PB buffers=10
show dots=on
# all main sections must start in column 1, indent local material.

# Protocol "IPX" is for Novell's IPXODI
Protocol IPX
    Bind #1

# Protocol "Kermit" is for MS-DOS Kermit
Protocol KERMIT
    Bind EXOS

Link Support
    buffers 6 1514
    MemPool 2048

Link Driver exos
    Port  310 20
    Mem   000D0000 400
    Int   5
    frame Ethernet_II
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

Link Driver SMCPLUS
    Port  280 20
    Mem   000CA000 2000/10
    Int   7
    frame Ethernet_II
    frame Ethernet_Snap
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

# Protocol "TCPIP" is for Novell's Lan WorkPlace for DOS, not Kermit
Protocol TCPIP
    ip_address    129.123.1.99
    ip_router    129.123.1.254
    ip_netmask    255.255.255.0
    tcp_sockets    8
    udp_sockets    8
    raw_sockets    1
    nb_sessions    4
    nb_commands    8
    nb_adapter    0
    nb_domain    usu.edu

Link Driver SLIP_PPP
    DIRECT    YES
    BAUD     9600
    OPEN    ACTIVE
    PCOMP    YES
    ACCOMP    YES
    PORT    3F8
    INT    4
    FRAME    SLIP
    Protocol    IP    0800    SLIP

MAKING NOVELL SLIP_PPP ODI CONNECTIONS

Novell's SLIP_PPP ODI driver is a combined serial port SLIP and PPP module
which is part of the Lan WorkPlace for DOS (LWP) product.  Kermit requires
the line:

    Protocol    IP    0800    SLIP

to be included with the driver.     Note that Kermit can temporarily steal the
serial port hardware from this driver to dial the telephone and log into a
host; SLIP/PPP communications should resume normally after Kermit is set to
the TCP/IP pathway.  Here is a STARTODI.BAT and NET.CFG example with SLIP_PPP
carrying the TCP/IP traffic.  File STARTODI.BAT:

@echo off
REM - Load LSL first
c:\lsl.com
REM - Then load your network board driver
c:\ne2000.com
REM - Then load the Novell SLIP_PPP driver
c:\slip_ppp.com
REM - Then the regular Novell IPX driver and network shell, for example:
set name=olga
c:\ipxodi /d
c:\bnetx.exe ps=name-of-novell-server
@echo on

File NET.CFG:

# File NET.CFG
PB buffers=6
show dots=on
signature level=0

protocol KERMIT
    bind SLIP_PPP
#    bind ne2000

Link Support
    Buffers    7 1500
    MemPool    2048

Link Driver NE2000
    Port  360
    Int   5
    Frame    Ethernet_II
    Protocol    IPX    8137    Ethernet_II
    Protocol    IP    0800    Ethernet_II
    Protocol    ARP    0806    Ethernet_II
    Protocol    RARP    8035    Ethernet_II

Link Driver SLIP_PPP
    DIRECT    YES
    BAUD     9600
    OPEN    ACTIVE
#    TCPIPCOMP    VJ
    PCOMP    YES
    ACCOMP    YES
    PORT    3F8
    INT    4
    FRAME    SLIP
#    FRAME    PPP
    Protocol    IP    0800    SLIP

# Below is for Novell's Lan WorkPlace for DOS
Protocol TCPIP
    PATH SCRIPT    d:\lwp41\net\SCRIPT
    PATH PROFILE    d:\lwp41\net\PROFILE
    PATH LWP_CFG    d:\lwp41\net\HSTACC
    PATH TCP_CFG    d:\lwp41\net\TCP
    ip_router    129.123.100.254
    ip_netmask    255.255.255.0
    ip_address    129.123.100.5
    tcp_sockets    16
    udp_sockets    8
    raw_sockets    1
#    nb_sessions    4
#    nb_commands    8
#    nb_adapter    0
#    nb_domain    usu.edu
    Bind        slip_ppp

Kermit is told to bind to SLIP_PPP rather than to the active NE2000 board
because the indented minor clause Bind SLIP_PPP under the Protocol Kermit
major heading tells Kermit which MLID (board driver) to use.  Link Driver
SLIP_PPP has indented Kermit line "Protocol IP 0800 SLIP" so Kermit can use
the driver; ARP and RARP lines could have been added with no effect (no ARP on
a point-to-point link).     LWP/DOS does not need this protocol line because it
tends to generate them itself.

Either SLIP or PPP can be used by setting the Frame Type and using the same
frame type in the indented protocol line below it.  No NetBios support was
wanted from LWP/DOS so that section was commented out.

STARTODI.BAT loads SLIP_PPP but nothing is sent out immediately as there is
not yet any connection.     To make the connection, start Kermit, SET PORT COM1
(or whatever), set the desired speed and flow control (but not Xon/Xoff!),
dial the phone and log into the host or server, then start SLIP or PPP there
(Novell provides a DIALER program with SLIP_PPP which can set the port speed
and dial a phone number via rudimentary means; Kermit is much more flexible
about this).  In all this, Kermit is grabbing the serial port from SLIP_PPP,
using it, and then returning it when done.  Kermit's TELNET will find an ODI
driver, SLIP_PPP, adjust itself accordingly, and SLIP-style packets flow back
and forth.  (If Kermit doesn't find the ODI driver, tell it to SET TCP
PACKET-DRIVER ODI.)

ODI-TO-PACKET-DRIVER SHIMS

Prior to version 3.12, the only way to make TCP/IP connections over ODI with
MS-DOS Kermit was through the ODIPKT shim, which converts between the ODI
interface and the packet-driver interface.  ODIPKT is no longer necessary,
except under Windows (because there is, as yet, no equivalent of WINPKT for
ODI drivers).

There is an ODI to Packet Driver shim available for Token Ring cards which can
work with Kermit (and WINPKT).    The current version is still in Beta as of
this writing (May 93).    ODITRPKT is available via FTP from Oklahoma State
University host datacomm.ucc.okstate.edu as pub/oditrpkt/beta9.zip.  A copy is
also available in packet-drivers/new on watsun.cc.columbia.edu, but it might
not be as up-to-date as the one at the source.

Here is a NET.CFG example using ODITRPKT:

LINK DRIVER TOKEN
     INT 3
     FRAME TOKEN-RING
     FRAME TOKEN-RING_SNAP
     PROTOCOL IPX  E0    TOKEN-RING
     Protocol IP   0800 TOKEN-RING_SNAP
     Protocol ARP  0806 TOKEN-RING_SNAP
     Protocol RARP 8035 TOKEN-RING_SNAP

And here is one using Arcnet:

LINK DRIVER SMCARCWS
     INT 3
     PORT 300
     MEM D0000
     Frame NOVELL_RX-NET
     Protocol IPX  FA NOVELL_RX-NET
     Protocol IP   D4 NOVELL_RX-NET
     Protocol ARP  D5 NOVELL_RX-NET
     Protocol RARP D6 NOVELL_RX-NET

At the moment there is no Windows support for Kermit over ODI.    Instead we
recommend using shim ODIPKT or ODITRPKT over ODI, followed by WINPKT over that
to employ a Packet Driver interface into Windows.

TCP/IP BUGS AND LIMITATIONS

Domain name resolution might not work when you give a nickname instead of a
complete host name in the SET PORT TCP/IP command and Kermit transforms the
nickname into the desired complete host name by combining it with your TCP/IP
DOMAIN.  Kermit does not use a special Hosts file to relate nicknames to
complete host names.  Workarounds: use a complete hostname, an IP host number,
or set your TCP/IP DOMAIN correctly.  It should be obvious that Domain Name
Servers are specified by their IP number rather than name.

Version 3.13 supports multiple gateways on the local network.  Choosing the
incorrect gateway normally results in that gateway sending an ICMP Redirect
message to Kermit indicating the preferred gateway, and Kermit displays such
messages.  Version 3.12 and earlier did not implement ICMP Redirect actions.

For IBM mainframe linemode TELNET connections, automatic appearance of the
login banner might not work.  Type a carriage return (Enter) to get the login
banner.     Local-echo and linemode operation are negotiated automatically.

BOOTP requests are handled correctly within the local network, and have been
tested successfully through Novell's BOOTP forwarder NLM and through Cisco
routers with software version 8.2.7.  In the SET TCP/IP ADDRESS command, the
words BOOTP and RARP must be spelled out in full.  Version 3.11 and 3.12
support original RFC951 and 1048 BOOTP protocol, and version 3.13 adds support
for downloading of the PC's full host (domain) name as specified in RFC1395.
See MSKERM.HLP (KERMIT.HLP) for details.

EXIT from Kermit closes your TCP/IP session (just like HANGUP).     PUSHing or
running DOS commands from Kermit keeps it open.     In version 3.12 and later,
EXITing while a session is active causes a warning / confirmation message to
appear so you can change your mind.

Version 3.11 of MS-DOS Kermit uses only the TELNET port (23) for SET PORT TCP
connections.  Version 3.12 and later allow you to specify any desired port
(except 25) in the SET PORT TCP command, after the host name or address.

MS-DOS Kermit honors TELNET protocol negotiations, including terminal type and
ECHO/SGA.  Version 3.11 always sends "VT100" as its terminal type; later
versions send MS-DOS Kermit's active terminal type or allows the user to
create an override string with command SET TCP/IP TELNET-TERM-TYPE.

Not supported: FTP, TFTP, automatic setting of PC date/time from network, 3270
emulation (tn3270), etc.  There is no PING command, but MS-DOS Kermit responds
when PINGed and when probed by Traceoute.  The keyboard verb \Knethold does
nothing.  Multiple simultaneous TCP/IP sessions are supported in version 3.13;
see MSKERM.HLP (KERMIT.HLP) for details.

For TCP/IP connections to IBM mainframes in full screen 3270 mode, you need an
intermediate host or device to do the 3270/ASCII terminal conversion.  Typical
setup is a TCP/IP terminal server with its serial lines connected to a protocol
converter (e.g. IBM 7171), a UNIX host that has tn3270 available, or a terminal
server (like Cisco) that does 3270 terminal emulation.    To transfer files with
an IBM mainframe, you might have to tell MS-DOS Kermit to SET PARITY SPACE.

Version 3.12 and later support inbound connections to MS-DOS Kermit.  Inbound
TELNET connections do not copy DOS screens, etc, like Carbon Copy and PC
Anywhere and the free telnetd program of Erick Engelke; a Kermit-to-Kermit
connection is made instead.  To configure MS-DOS Kermit to be a TCP/IP server,
give the following command:

  SET PORT TCP * [ <port> ]
  SET SERVER LOGIN <username> [ <password> ]  ; (recommended but not required)
  SERVER

Use asterisk instead of an IP name or address, followed optionally by a TCP
port number (the default is 23 = TELNET), and then enter server mode.  Anybody
who TELNETs to your PC will see a brief screen message telling them to escape
back to their local Kermit prompt and issue commands from there, for example:

  REMOTE LOGIN <usename> <password>
  REMOTE DIRECTORY
  GET OOFA.TXT

Kermit's TCP/IP support cannot be used simultaneously with PC NFS because both
applications want to register use of ARP and IP with the packet driver, but
each protocol can only be assigned to one application.  This is only one
particular case of the more general rule:

    Only one TCP/IP based application can use a LAN adapter at once.

which also applies to DesqView/X and other TCP/IP products for the PC.

(There is a program called PKTMUX that, under some conditions, might allow
coexistence of multiple TCP/IP applications, but it is risky and not
recommended.)  To make MS-DOS Kermit work simultaneously with PC-NFS, Kermit
would have to be linked with the proprietary socket-library routines, which we
cannot do.  If you need to have NFS active simultaneously with an MS-DOS
Kermit TCP/IP connection, it is best to use a different NFS package that also
works with Kermit such as FTP Software, Novell LWP, or Beame and Whiteside.

The SET TCP/IP and SET PORT TCP/IP commands only return failure codes if there
is a parse error.  The connection is not opened until the first attempt to
communicate with the remote host: CONNECT, PAUSE, OUTPUT, etc.    While
connection establishment is in progress, you can't interrupt the program with
Ctrl-C.     Use IF SUCCESS / FAILURE after PAUSE 0 to check if the connection
is open, for example:

  DEFINE TELNET SET PORT TCP \%1 \%2, PAUSE 0, IF SUCCESS CONNECT

The second variable above is for the optional TCP port number in version 3.12
and later.

TCP/IP performance hints: Set your Kermit packet size to 500 or larger to
achieve most data sent per network packet. A convenient setting is SET
RECEIVE PACKET 1000, SET WINDOW 4, resulting in four 1000-byte packets in a
window.     SET FLOW NONE lets TCP/IP do the flow control and eliminates Kermit's
need to check for Xon/Xoff.  In most situations beyond the local network
performance will be limited by the long distance lines rather than by the PC.

End of MSKERM.BWR / KERMIT.BWR